In general, there are only two forms of a data object in a program, instances and references. An instance is the actual data object that can be created statically by the compiler or dynamically by the application. A reference of a data object occurs when a function accesses a data object whose instance was created elsewhere, such as another function.
Ordinarily, all programs are comprised of one or more functions. Larger programs may have the sources for many of the functions stored in separate files for convenience of maintenance and to reduce compile time. Since the source for these large programs are stored in separate files, they are compiled into relocatable object files (i.e., “.” files), that have one-to-one correspondence with their source file. The compilation of these source files into the relocatable object files has a temporal nature. A relocatable object file derived from one source can be produced one month and a relocatable object file derived from another source file can be produced in another month. A resulting program can then be constructed by linking two relocatable object files at a third time without compromising the correctness of the program. This linking without compromising the correctness of the program is provided on the condition that none of the source files are changed between the compilation of the first source file and the compilation of the second source file.
This utilization of the relocatable object file derived from one source that can be produced in one month, and accessed and re-utilized in other modules at a later time normally will not have type checking errors caught by the linker. This is especially true during the development of the multiple code modules, in that the program can then have a high failure rate during execution. Therefore, there is a need for the developers to have the ability to have type checking performed at run-time to ensure run-time program correctness. This run-time type checking is needed because of inconsistent references to objects that change over time.
There is also a great need to make this type checking temporary, because once the developers have ensured the run-time correctness of the program there is additional overhead caused in space or time to perform this run-time type checking on an ongoing basis. This run-time type checking need not be performed when the program is in normal production or is being utilized by the end user. There is also the need to have the run-time type checking performed on an as needed basis (i.e. switchable) should errors occur during normal operation. This switchable run-time type checking would allow for the debugging of the program modules at a later time by switching the run-time type checking to an on-mode to assist in debugging of the programs. In order to have this switchable, there is a need to allocate the space required for a methodology to perform the run-time type checking at any time desired.
There is the additional problem that arises if one of the relocatable object files is produced from a first source, and there is a data object declaration in a second source. The problem arises where the data object, used by both of the source files, is changed and a second relocatable object file is produced from the second source file. Then, the two relocatable object files will contain data object declarations that are incompatible, but not detectably different.
Thus, a heretofore unaddressed need exists in the industry to address the aforementioned and/order inefficiencies and inadequacies of computer software.